Skip to content

Conversation

@teor2345
Copy link
Member

@teor2345 teor2345 commented Oct 15, 2025

This PR backports the latest compatible Proof of Space changes from abundance, including some API refactors, including all relevant files up until commit:
nazar-pc/abundance@6d56b48

It should be reviewed one commit at a time.
The copied code is best reviewed by:

  • checking out abundance at that commit
  • copying across the code from abundance
  • checking there are no differences

The copied code includes:

  • ab-proof-of-space replacing subspace-proof-of-space
  • ab-chacha8 copied into shared
  • SolutionPotVerifier trait from ab-core-primitives

Various minor fixes are then made to get it to compile and pass CI:

  • Cargo.toml build files
  • imports
  • incompatibilities
  • revert dependency and compiler changes we haven't updated to yet
  • clippy/lint fixes
  • missed docs

I also added some extra tests and benchmark debugging.

Code contributor checklist:

nazar-pc and others added 3 commits October 15, 2025 15:44
…ace (nazar-pc/abundance#406)

Using the entire ab-proof-of-space as at commit:
nazar-pc/abundance@6d56b48

And merge changes from ab-proof-of-space/Cargo.toml into subspace-proof-of-space/Cargo.toml.
@teor2345 teor2345 self-assigned this Oct 15, 2025
@teor2345 teor2345 added enhancement New feature or request performance Related to performance measurement or improvement labels Oct 15, 2025
@immunefi-magnus
Copy link

🛡️ Immunefi PR Reviews

We noticed that your project isn't set up for automatic code reviews. If you'd like this PR reviewed by the Immunefi team, you can request it manually using the link below:

🔗 Send this PR in for review

Once submitted, we'll take care of assigning a reviewer and follow up here.

@teor2345 teor2345 enabled auto-merge October 15, 2025 13:50
@teor2345
Copy link
Member Author

The benchmark failure might take some time to fix, and I've run out of time today. Looks like the benchmarks expect Proof of Space to return Ok, but instead it's returning an error.

The "check individually" failure is trivial, just some missing dead code annotations.

Copy link
Member

@nazar-pc nazar-pc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that miri annotations may not be necessary since this repo doesn't run tests under Miri (abundance does to have additional guarantees that unsafe code maintains invariants, but some tests are too slow to run regularly in CI or impractical to run in general, hence corresponding annotations).

Similarly no-panic ensures compiler can figure out the code can't possibly panic at compile time, which allows for better optimizations, but this repo doesn't run corresponding tests, so not sure how useful it is to port over.

Copy link
Contributor

@vedhavyas vedhavyas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did a review but not confident in my review yet due to big number of changes in the first PR Commit itself.

Ignored tests and benchmarks for this review

Some of the later commits can be merged up as they add no extra benefit for review


impl ab_core_primitives::solutions::SolutionPotVerifier for ChiaTable {
fn is_proof_valid(seed: &PosSeed, challenge_index: u32, proof: &PosProof) -> bool {
Tables::<K>::verify_only(seed, challenge_index.to_le_bytes(), proof)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is the behaviour same for verify and verify_only ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

verify follows Chia API and returns the quality back. verify_only doesn't compute the quality, just verification. The verification itself is reused and is identical. You can see the logic in the fn verify, it has exactly one branch.


// TODO: More idiomatic version currently doesn't compile:
// https://github.com/Rust-GPU/rust-gpu/issues/241#issuecomment-3005693043
#[allow(clippy::needless_range_loop)]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

confused here with this clippy allowed warning. Is this allow required ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is required for GPU implementation, but not for CPU. It is just pulled from the codebase where GPU support is already partially implemented and this was needed to make it both compile and not complain.

@teor2345
Copy link
Member Author

teor2345 commented Oct 22, 2025

Note that miri annotations may not be necessary since this repo doesn't run tests under Miri (abundance does to have additional guarantees that unsafe code maintains invariants, but some tests are too slow to run regularly in CI or impractical to run in general, hence corresponding annotations).

Similarly no-panic ensures compiler can figure out the code can't possibly panic at compile time, which allows for better optimizations, but this repo doesn't run corresponding tests, so not sure how useful it is to port over.

I'm trying to minimise the diff with abundance, so the next backport is easier.

Some of the later commits can be merged up as they add no extra benefit for review

I'd like to keep them separate so they're easier to revert, if we need to do that in the next backport. It's also useful to have the backport steps clearly listed.

Edit: I squashed some similar commits

@teor2345 teor2345 force-pushed the abundance-pos-backport branch from 838b880 to fa44a46 Compare October 22, 2025 22:08

// Check that proof of space is valid
if !PosTable::is_proof_valid(
if !<PosTable as SolutionPotVerifier>::is_proof_valid(
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nazar-pc in the subspace benchmarks, I'm getting an InvalidProofOfSpace error here:

I'm not sure if:

  • my changes in this PR have broken verification (I've checked and none of my commits should change the result)
  • there's an unexpected incompatibility in the abundance source commit
  • the benchmark is wrong in some way, and this code is stricter
  • the abundance code doesn't handle unlimited solution ranges
  • some other issue

Does anything seem obvious to you?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nothing obvious from a quick look, but I have not audited the code. Try to start a local node and farmer, see if it can produce blocks. Even with changed logic for constructing tables, if challenge is derived the same way, verification should succeed. Something is significantly wrong if verification doesn't pass.

You can also add verification right after proof generation and dump the seed and challenge index for which verification fails. You can then update tests to check that particular seed both here and in abundance repo to see where things do not match.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using the hard-coded vote.data, which is decoded using VoteData, I get a failure in ShimTable (only used for tests) at:

Which means no solution was found.

This happens because ab-proof-of-space inverted the ShimTable logic, I've reverted to the current Subspace logic, and the benchmarks pass.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not changing the vote data to match updated shim implementation then? Also if benchmarks are running shim implementation instead of Chia, that doesn't seem right.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not changing the vote data to match updated shim implementation then?

I wasn't in the mood for mucking around with binary files 😂

But seriously, if we are just going to change to the real implementation in the next PR, there's no point in changing the vote data in this one as well.

Also if benchmarks are running shim implementation instead of Chia, that doesn't seem right.

I had that thought as well. Happy to move to the real implementation in another PR.

If there's any expensive setup we can put it outside the benchmarked code. (Or in a OnceCell if it's very expensive.)

@vedhavyas @jfrank-summit what do you think?

teor2345

This comment was marked as resolved.

@teor2345 teor2345 force-pushed the abundance-pos-backport branch 2 times, most recently from 2e8bf24 to 84dc9fa Compare October 24, 2025 04:10
@teor2345 teor2345 force-pushed the abundance-pos-backport branch from 84dc9fa to c019daa Compare October 24, 2025 07:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request performance Related to performance measurement or improvement

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants